Media Gateway Controller (MGC) and Media Gateway (MG) are two important components of Next Generation Network (NGN). MGC is responsible for call control, and MG is responsible for service carrying, thereby implementing separation of the call controlling surface and the service carrying surface, so as to make full use of network resources, simplify the equipment upgrade and service expansion, and lower the development and maintenance cost greatly, as shown in FIG. 1.
Media gateway control protocol is the main protocol for the communication between MG and MGC, wherein H.248/MeGaCo and MGCP are two widely-used protocols at present. Therein, MGCP protocol was established in October 1999 and revised in January 2003 by IETF, and H.248/MeGaCo protocol was established in November 2000 and revised in June 2003 by IETF and ITU together.
Taking H.248 protocol as an example, all kinds of resources on MG are abstractly represented as Termination. There are two kinds of Termination: physical Termination and temporary Termination, the former representing some semi-permanently existing physical entity, e.g., Time Division Multiplexing (TDM) channel etc, and the latter representing some public resources which are temporarily applied for and will be released after use, e.g., Real-time Transport Protocol (RTP) stream etc. A combination of Terminations is abstractly represented as Context. A Context may include a plurality of Terminations, so Topology is used to describe the relation between the Terminations.
Based on this abstract model of protocol, the connection of a call is actually the operation to Termination and Context. This operation is carried out by the Command request and response between MGC and MG. Parameter carried by Command, also referred to as Descriptor, is divided into the following categories: Property, Signal, Event, Statistic, etc. The parameters with service correlation are aggregated logically into a Package.
Because call control and service carrying are carried out on the two separate components, MGC and MG, respectively, and the communication between MGC and MG is performed based on the packet network NGN, it is important for one of MGC and MG to know whether the other operates normally. Especially MG is usually in a passive position as a controlled part, unlike MGC, which can actively inquire the MG it controls by using audit method flexibly, so it is more desirable for the media gateway control protocol to provide efficient means for it to monitor the status of MGC.
The Inactivity Timer package, the Inactivity Timeout event of the package, and the Maximum Inactivity Time parameter of the event, defined in H.248 protocol, provide means for MG to monitor the status of MGC. The following is the mechanism thereof.
MGC sends Inactivity Timeout event of Inactivity Timer package to the Root Termination on MG, which represents the gateway as a whole, and sets the Maximum Inactivity Time parameter of the event, directing MG to start to detect whether the silent time of the message from MGC exceeds the value of the parameter. MG detects all incoming messages based on the above. Once the silent time of the message from MGC exceeds the value of the parameter, MG reports to MGC by sending a Notify message attached with Inactivity Timeout event. If there is no response to this Notify message, MG will deem MGC as faulty and start an abnormity processing flow, e.g. initiate registration with a standby MGC.
In order to let MG know it is in normal status, MGC should ensure the interval of the messages sent to MG not exceed the set value of the Maximum Inactivity Time parameter, so that if there is no service control message needed to be sent during this period, MGC needs to send an additional message, such as that for test or keeping active, e.g., send a null audit value message to the Root Termination on MG.
There are two ways for MG to detect the message silent time of MGC. One is to provide a timer with an initial value of 0 and with an upper limit for timeout. Each message from MGC will trigger the timer to be reset to 0, and once the timer is timeout, Inactivity Timeout event will be reported to MGC. The other way is to provide a message receiving flag with an initial value of 0 and a general timeout timer. Each message from MGC will trigger the flag to be set to 1, and if the timer is timeout and the flag remains 0, Inactivity Timeout event will be reported to MGC; otherwise, MG will reset the mark to 0 and restart the timer.
The above solution has the following shortcomings:
1. The mechanism for MG to monitor status of MGC can only be started after MGC sends corresponding package, event and parameter. If, for the following possible reasons, MG does not receive these messages, MG will lose the valid mechanism for monitoring the status of MGC: MGC has not implemented the package, not configured to send the package, not sent the message in time due to an abrupt fault, or the sent message has been missed accidentally, or whatever.
2. The mechanism for MG to monitor status of MGC ensures the message interval is not timeout, depending on sending a special message that is not for service control by MGC, which not only adds extra burden to MGC, but also adds extra traffic to network, and which, however, can not ensure that the MGC message silent timeout does not occur on MG. As a result, MG still has to make judgments according to whether there is any response to the Notify message.